3.1 Software Requirements（整理版）

原始笔记: Software Requirements.md 原始教程: 3.1 Software Requirements created: 2026-07-26 14:53 整理说明: 本版本保持原笔记已有的需求分类与示例，只用教程补充这些概念之间的关系和术语解释。

内容简要概括

软件需求可以从业务、用户和解决方案三个层次理解：业务需求解释项目为什么值得做，用户需求说明利益相关者需要获得什么能力，解决方案需求再把这些目标转化为可实现、可验证的功能和约束。三类需求应当能够相互追溯，避免软件实现偏离最初的业务价值。

Business Requirements、User Requirements、Stakeholder Requirements、Solution Requirements、Functional Requirements、Non-functional Requirements、需求追溯、质量约束

目录

• 1. 需求的三个层次
• 2. Business Requirements
• 3. User or Stakeholder Requirements
• 4. Solution Requirements
• 5. 需求之间的追溯关系

1. 需求的三个层次

需求可以采用多种分类方式。一个实用的高层划分是：

这三类需求不只是同一件事的不同详细程度。它们代表不同利益相关者的视角，也使用不同的目标和语言。

2. Business Requirements

业务需求站在组织、公司或研究机构的角度，描述项目希望实现的战略目标，例如：

• 提高利润率；
• 扩大市场份额；
• 开拓新的研究方向；
• 建立新的合作关系。

它回答的是：

这个项目为什么值得做？它要为组织带来什么价值？

2.1 如何判断是不是业务需求

一个合格的业务需求通常满足三个特点：

1. 站在组织视角，而不是单个用户视角；
2. 描述目标或价值，而不是具体功能；
3. 与项目战略相关，能够解释项目存在的理由。

例如：

• “降低临床报告的审计风险”是业务需求；
• “报告中增加标准差”是功能或解决方案需求；
• “报告必须在 30 秒内生成”通常属于用户期望或非功能需求。

2.2 原笔记示例

• BR1：提高临床试验报告的统计质量，以满足外部审计需要；
• BR2：提高试验分析吞吐量，以应对高峰期更高的需求。

3. User or Stakeholder Requirements

用户或利益相关者需求描述特定群体希望最终系统提供什么能力，是业务目标与具体软件实现之间的桥梁。

它回答的是：

为了实现业务目标，某类利益相关者需要完成什么事情或获得什么结果？

3.1 如何判断是不是用户需求

用户需求通常具有以下特点：

• 明确对应某类利益相关者；
• 描述用户期望获得的能力或结果；
• 能够追溯到某个业务需求；
• 不深入指定技术实现。

3.2 原笔记示例

• UR1.1（来自 BR1）：按照修订后的审计标准，在生成的试验报告中支持标准差等统计量；
• UR1.2（来自 BR1）：按照修订后的审计标准，支持在试验报告中生成统计结果的文本表示；
• UR2.1（来自 BR2）：单份试验报告能够在 30 秒内处理并生成。

UR1.1 和 UR1.2 描述用户需要的结果，没有规定具体的模块、函数或数据结构。UR2.1 则提出了用户可以感知的性能目标。

4. Solution Requirements

解决方案需求描述软件为了满足用户需求而必须具备的具体特征。

它回答的是：

为了满足用户需求，软件具体必须具备什么能力和约束？

解决方案需求可以进一步分为 Functional Requirements 和 Non-functional Requirements。

4.1 Functional Requirements

功能需求关注解决方案“做什么”，即需要提供的功能和特性。

原笔记示例：

• SR1.1.1（来自 UR1.1）：在数据模型中加入标准差，并提供图形可视化视图；
• SR1.2.1（来自 UR1.2）：新增用于生成统计量文本表示的视图，并通过可选命令行参数调用。

这些需求已经进入可实现的产品行为层面：需要修改数据模型、视图和命令行接口。

4.2 Non-functional Requirements

非功能需求关注软件行为“如何表现”或受到哪些约束，常见类别包括：

• 性能；
• 安全性；
• 可用性；
• 可移植性。

非功能需求也称为 Quality of Service Requirements。

原笔记示例：

• SR2.1.1（来自 UR2.1）：在临床工作站配置上，于 30 秒内生成图形统计报告。

该需求没有增加新的业务功能，而是为已有报告功能规定了运行环境和性能上限。

5. 需求之间的追溯关系

需求编号可以帮助记录上下层关系：

CopyBR1
├── UR1.1
│   └── SR1.1.1
└── UR1.2
    └── SR1.2.1

BR2
└── UR2.1
    └── SR2.1.1

这种追溯关系便于检查：

• 每个解决方案需求是否服务于真实的用户需求；
• 每个用户需求是否支持明确的业务目标；
• 修改或删除某项需求时，哪些上下游需求会受到影响；
• 测试结果最终能够验证哪项需求。

需求编号本身没有唯一标准，关键是团队采用一致、清晰且可追踪的命名方式。